現在，我們已經有了吃吃記帳的產品發想、人物誌 Persona、使用者故事 User Story，和顧客旅程地圖 Customer Journey Map，還有流程圖 Flow Chart。

在進入正式開發前，我還有一個任務--設定最小可行性產品 (Minimum Viable Product)。

為什麼要設定 MVP

相信大家都有體驗過，自己花很多時間做一個東西，最後發現跟對方想要的內容天差地遠的情況。
我想是因為人與人之間的溝通是複雜的，在沒有實體的東西查看的情況下，對成品的理解只存在彼此的想像裡，很難完全的達成共識。或者，有時候我們概念想得很美好，但實際做出來的成果，無法達成最初的期望。

因此，為了避免資源和時間的浪費，我們可以先做出具備基本功能的模型，進行價值與使用的測試，確認開發的方向是否正確。等確認可行後，再逐漸地增添、完善這個產品。

而對我來說，我需要 MVP 來幫我確認初步產品的「邊界」在哪裡。因為作為獨立操作 no-code 工具的開發者，技術問題通常需要大量時間研究解決，一次開發太多內容，想要盡善盡美，會是很大的負擔。為了妥善的利用時間，我需要區分「must have」和 「good to have」的內容，先以核心的功能為主要目標。

設定吃吃記帳的 MVP

為了確認 MVP，我又更新、檢查了所有使用者故事。在九個基礎故事中，我選出三個最核心的故事來拆解，其他我認為「錦上添花」的故事就先暫時放在一邊。
這三個 EPIC 總共拆出了七個功能，和他們各自的User Stories，參考圖片如下。
我也利用了紅色標籤，把屬於 MVP 的故事標注出來。

對於要選擇哪些故事納入 MVP，我的考量如下：

1. 是否對使用者產生最大的價值
   我必須斟酌，這個功能是必要的嗎？如果沒有這個功能，是不是大多數的使用者都會感到不滿、不方便？
   在這樣的自我詢問下，我篩選出最重要的基本功能，像是紀錄飲食、計算熱量等。而像最開始我很想做的「超加工食物提醒」，就是一個非核心的功能，可以後續再做決定。

2. 服務的穩定性和成本
   除了使用者的需求，我也考慮了技術的實現問題。
   舉例來說，我很希望使用者可以拍照食物來代替飲食紀錄，這是最小摩擦力的設計。可是考慮到能辨識照片的 AI 模型並不是很多，有些不是很準確，而且運行模型可能會消耗大量 token，導致成本增加。
   因此，我後來選擇把最基礎、最穩定「文字輸入」變成 MVP，而照片和語音輸入，列為後續迭代的範疇。

3. 是否會影響服務流程
   當我在考量是否要納入某個故事為 MVP 時，也要確認它在整體流程上的位置。
   像是「設定紀錄飲食的提醒」是很貼心的服務，但一來不是每個使用者都需要提醒，二來我擔心有技術上的困難(定時觸發功能是要設定在 Line 還是 Bot 上？如何記錄每個使用者不同的提醒需求？)，因此我檢查流程圖，確認跳過這個步驟，並不會影響我後續的流程，就可以安心地把它放在後續迭代的範圍。

MVP 對我的幫助

在前面幾篇文章中，我提到對於「查詢歷史紀錄」這一功能的困惑--個人覺得有這項功能會很好，但是在技術上一直想不到該怎麼用 no-code 工具實現：是把 Line Bot 的對話紀錄拋到 Airtable 上，再建立一個網站給使用者查詢嗎？或是串 API 到 Notion，給每個使用者建立單獨的頁面去查看？總之我絞盡腦汁，都想不出一個效果好，又不需要寫程式的解決方案。
後來朋友提醒我，這真的是一個必要的功能嗎？ 我回過頭來查看使用者故事，並認真思考了 MVP 之後，發現我根本不需要煩惱這個問題，因為這並不是最核心的需求。想通之後，覺得放下心中的大石頭，安心的把重點轉移到其他功能上。

根據 MVP 更新Jira的內容

有了明確的 MVP 範疇後，我也同步更新了我的 Jira，設定了一個 MVP 的標籤。

那麼到這邊，第一階段的產品的發想與規劃基本上就完成了。接下來，我要進入第二階段--產品的開發，開始設定吃吃記帳的 Bot 。